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FOREWORD 


This  publication  is  issued  by  the  National  Computer  Security  Center 
(NCSC)  as  part  of  its  program  to  promulgate  technical  computer  security 
guidelines.  This  interpretation  extends  the  Department  of  Defense  Trusted 
Computer  System  Evaluation  Criteria  (DOD  5200.28-STD)  to  computer 
security  subsystems. 

This  document  will  be  used  for  a  period  of  at  least  one  year  after  date  of 
signature.  During  this  period  the  NCSC  will  gain  experience  using  the 
Computer  Security  Subsystem  Interpretation  in  several  subsystem 
evaluations.  After  this  trial  period,  necessary  changes  to  the  document  will  be 
made  and  a  revised  version  issued. 

Anyone  wishing  more  information,  or  wishing  to  provide  comments  on  the 
usefulness  or  correctness  of  the  Computer  Security  Subsystem  Interpretation 
may  contact:  Chief  Technical  Guidelines  Division,  National  Computer 
Security  Center,  Fort  George  G.  Meade,  MD  20755-6000,  ATTN:  Cll. 


PATRICK : 

Director 

National  Computer  Security  Center 


16  September  1988 
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1.  INTRODUCTION 

This  document  provides  interpretations  of  the  Department  of  Defense  Trusted 
Computer  System  Evaluation  Criteria  (DoD  5200.28-STD  or  TCSEC)  for  computer 
security  subsystems.  A  computer  security  subsystem  (subsystem)  is  defined,  herein, 
as  hardware,  firmware  and/or  software  which  can  be  added  to  a  computer  system  to 
enhance  the  security  of  the  overall  system.  A  subsystem’s  primary  utility  is  to  increase 
the  security  of  a  computer  system.  The  computer  system  that  the  subsystem  is  to 
protect  is  referred  to  as  the  protected  system  in  this  Interpretation. 

When  incorporated  into  a  system  environment,  evaluated  computer  security 
subsystems  may  be  very  effective  in  reducing  or  eliminating  certain  types  of 
vulnerabilities  whenever  entire  evaluated  systems  are  unavailable  or  impractical. 

1.1  PURPOSE 

This  Interpretation  has  been  prepared  for  the  following  purposes: 

1.  to  establish  a  standard  for  manufacturers  as  to  what  security  features  and 
assurance  levels  to  build  into  their  new  and  planned  computer  security 
subsystem  products  to  provide  widely  available  products  that  satisfy  trust 
requirements  for  sensitive  applications; 

2.  to  provide  a  metric  to  evaluate  the  degree  of  trust  that  can  be  placed  in  a 
subsystem  for  protecting  classified  and  sensitive  information; 

3.  to  lend  consistency  to  evaluations  of  these  products  by  explicitly  stating  the 
implications  that  are  in  the  TCSEC;  and 

4.  to  provide  the  security  requirements  for  subsystems  in  acquisition  specifications. 

1.2  BACKGROUND 

The  Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria  (DoD 
5200.28-STD  or  TCSEC)  was  developed  to  establish  uniform  DoD  policy  and 
security  requirements  for  ’’trusted,  commercially  available,  automatic  data  processing 
(ADP)  systems.”  Evaluation  criteria  defined  in  the  TCSEC  provides  a  standard  to 
manufacturers  as  to  what  security  features  to  build  into  their  commercial  products  to 
satisfy  trust  requirements  for  sensitive  applications,  and  serves  as  a  metric  with  which 
to  evaluate  the  degree  of  trust  that  can  be  placed  in  a  computer  system  for  the  secure 
processing  of  classified  or  other  sensitive  information. 

The  TCSEC  specifies  a  variety  of  features  that  a  computer  system  must  provide  to 
constitute  a  complete  security  system.  The  security  requirements  specified  in  the 
TCSEC  depend  on  and  complement  one  another  to  provide  the  basis  for  effective 
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implementation  of  a  security  policy  in  a  trusted  computer  system.  The  effectiveness 
of  any  one  security  feature  present  within  a  system  is,  therefore,  dependent  to  some 
degree  on  the  presence  and  effectiveness  of  other  security  features  found  within  the 
same  system.  Because  it  was  intended  to  be  used  only  for  systems  which  incorporated 
all  the  security  features  of  a  particular  evaluation  class,  the  TCSEC  does  not,  in  all 
cases,  completely  specify  these  interdependencies  among  security  features. 

In  addition  to  the  class  of  trusted  system  products,  there  exists  a  recognized  need 
for  a  class  of  computer  security  products  which  may  not  individually  meet  all  of  the 
security  features  and  assurances  of  the  TCSEC.  Instead,  these  products  may 
implement  some  subset  of  the  features  enumerated  in  the  TCSEC  and  can  potentially 
improve  the  security  posture  in  existing  systems.  These  products  are  collectively 
known  as  computer  security  subsystems. 

Evaluation  of  computer  security  subsystems  against  a  subset  of  the  requirements 
given  in  the  TCSEC  has  proven  an  extremely  difficult  task  because  of  the  implied 
dependencies  among  the  various  features  discussed  in  the  TCSEC.  As  a 
consequence,  interpretations  of  these  interdependencies  and  the  relative  merits  of 
specific  subsystem  implementations  have  been  highly  subjective  and  given  to 
considerable  variation. 

This  document  provides  interpretations  of  the  TCSEC  for  computer  security 
subsystems  in  an  effort  to  lend  consistency  to  evaluations  of  these  products  by 
explicitly  stating  the  implications  in  the  TCSEC. 

Evaluations  can  be  divided  into  two  types:  (1)  a  product  evaluation  can  be 
performed  on  a  subsystem  from  a  perspective  that  excludes  the  application 
environment,  or  (2)  a  certification  evaluation  can  be  done  to  assess  whether 
appropriate  security  measures  have  been  taken  to  permit  an  entire  system  to  be  used 
operationally  in  a  specific  environment.  The  product  evaluation  type  is  done  by  the 
National  Computer  Security  Center  (NCSC)  through  the  Trusted  Product  Evaluation 
Process  using  this  interpretation  for  subsystems.  The  certification  type  of  evaluation 
is  done  in  support  of  a  formal  accreditation  for  a  system  to  operate  in  a  specific 
environment  using  the  TCSEC. 

1.3  SCOPE 

This  document  interprets  the  security  feature,  assurance  and  documentation 
requirements  of  the  TCSEC  for  subsystem  evaluations.  In  this  interpretation,  the 
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functional  requirements  of  the  TCSEC  are  divided  into  four  general  categories: 

1.  Discretionary  Access  Control  (DAC) 

2.  Object  Reuse  (OR). 

3.  Identification  and  Authentication  (I&A) 

4.  Audit  (AUD) 

These  categories  form  the  basis  for  classifying  products  to  be  evaluated  as  computer 
security  subsystems. 

The  document,  in  addition  to  this  introductory  section,  is  organized  into  three 
major  sections  and  a  glossary.  Section  2  contains  the  feature  requirements  for  each  of 
the  above  four  categories  on  which  subsystems  evaluations  are  based.  The 
requirements  in  this  section  are  listed  in  increments,  with  only  new  or  changed 
requirements  being  added  for  each  subsequent  class  of  the  same  feature.  All 
requirements  that  are  quoted  from  the  TCSEC  are  in  bold  print  for  easy  identification 
and  are  clarified,  in  the  context  of  subsystems,  by  interpretation  paragraphs. 

Section  3  contains  the  assurance  requirements  for  all  subsystems.  The  assurances 
that  are  relevant  to  each  category  are  listed  here  in  the  same  format  as  the 
requirements  in  Section  2.  Section  4  contains  the  requirements  and  interpretations  for 
subsystem  documentation,  again,  in  the  same  format  as  Section  2. 

The  TCSEC-related  feature  and  assurance  requirements  described  herein  are 
intended  for  the  evaluation  of  computer  security  subsystems  designed  to  protect 
sensitive  information.  This  Interpretation,  like  the  TCSEC,  assumes  that  physical, 
administrative,  and  procedural  protection  measures  adequate  to  protect  the 
information  being  handled  are  already  in  place. 

This  Interpretation  can  be  used  to  support  a  certification  evaluation.  In  fact,  it 
would  be  helpful  whenever  subsystems  are  a  part  of  the  overall  system  being  certified. 

1.4  EVALUATION  OF  SUBSYSTEMS 


1.4.1  Basis  for  Evaluation 

Subsystems  are  evaluated  for  the  specific  security-relevant  functions  they  perform. 
This  Interpretation  interprets  the  relevant  TCSEC  requirements  for  each  function 
evaluated.  So  the  function(s)  for  which  subsystems  are  evaluated  will  be  identified 
within  its  ratings.  Each  function  has  its  own  set  of  ratings  as  identified  in  Table  1.1. 
Subsystems  that  are  evaluated  for  more  than  one  function  will  receive  a  separate 
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rating  for  each  function  evaluated. 


TABLE  1.1.  Possible  Subsystem  Ratings 


SUBSYSTEM  FUNCTION 

POSSIBLE  RATINGS 

Discretionary  Access  Control 

DAC/D 

DAC/Dl 

DAC/D2 

DAC/D3 

Object  Reuse 

OR/D 

OR/D2 

Identification  &  Authentication 

I&A/D 

I&A/Dl 

I&A/D2 

Audit 

AUD/D 

AUD/D2 

AUD/D3 

Although  the  requirements  for  subsystems  are  derived  from  the  TCSEC,  the 
ratings  for  subsystems  will  not  directly  reflect  the  TCSEC  class  they  are  derived  from. 
Since  subsystems,  by  their  very  nature,  do  not  meet  all  of  the  requirements  for  a  class 
Cl  or  higher  computer  system,  it  is  most  appropriate  to  associate  subsystem  ratings 
with  the  D  division  of  the  TCSEC.  This  Interpretation  defines  the  Dl,  D2  and  D3 
classes  within  the  D  division  for  subsystems.  The  Dl  class  is  assigned  to  subsystems 
that  meet  the  interpretations  for  requirements  drawn  from  the  Cl  TCSEC  class. 
Likewise,  the  D2  class  consists  of  requirements  and  interpretations  that  are  drawn 
from  the  C2  TCSEC  class.  The  D3  subsystem  class  is  reserved  for  DAC  subsystems 
and  audit  subsystems  that  meet  the  B3  functionality  requirements  for  those  functions. 

In  addition  to  meeting  the  functionality  requirements  and  interpretations, 
subsystems  must  also  meet  the  assurance  and  documentation  requirements  in  sections 
3  and  4  of  this  document.  The  Dl  and  D2  classes  have  requirements  and 
interpretations  for  assurances  and  documentation  as  well  as  functionality.  The  D3 
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class  contains  additional  requirements  and  interpretations  only  for  functionality,  not 
for  assurances  or  documentation.  So,  subsystems  with  this  rating  will  adhere  to  the 
D2  assurance  and  documentation  requirements  and  interpretations. 

Like  the  classes  within  the  TCSEC,  the  Dl,  D2  and  D3  classes  are  ordered 
hierarchically.  Subsystems  being  evaluated  for  the  Dl  class  must  meet  the 
requirements  and  interpretations  for  the  Dl  class.  Subsystems  being  evaluated  for  the 
D2  class  must  meet  the  requirements  and  interpretations  for  the  Dl  class  plus  the 
additional  requirements  and  interpretations  for  the  D2  class.  Subsystems  being 
evaluated  for  the  D3  class  must  meet  the  additional  requirements  and  interpretations 
associated  with  the  functionality  at  D3. 

Although  the  subsystem  requirements  and  interpretations  are  derived  directly 
from  the  TCSEC,  subsystems  are  not  considered  to  be  complete  computer  security 
solutions.  There  is  no  general  algorithm  to  derive  a  system  rating  from  an  arbitrary 
collection  of  computer  security  subsystems.  Any  collection  of  individually  evaluated 
subsystems  must  be  evaluated  as  a  whole  to  determine  the  rating  of  the  resulting 
system.  The  ratings  of  the  individual  subsystems  in  a  complete  system  are  not  a  factor 
in  the  rating  of  that  system. 

1.4.2  Integration  Requirements 

Because  all  of  the  TCSEC  requirements  for  a  given  rating  class  were  intended  to 
be  implemented  in  a  complete  computer  security  system,  many  of  the  security  features 
are  dependent  upon  each  other  for  support  within  the  system.  This  poses  a  certain 
degree  of  difficulty  with  extracting  only  the  relevant  requirements  from  the  TCSEC 
for  a  given  feature.  Further,  this  poses  a  fundamental  problem  for  subsystems 
because  there  is  an  explicit  dependency  between  security  features  that  restricts  the 
’’independent”  incorporation  of  subsystems  into  the  system’s  environment.  The 
problem  has  been  handled  in  this  Interpretation  by  discussing  the  integration 
requirements  for  each  type  of  subsystem.  The  requirements  for  integration  are 
discussed  for  each  type  of  subsystem  in  a  sub-section  entitled,  ’’Role  Within  Complete 
Security  System.”  Furthermore,  explicit  requirements  for  integration  are  stated  in  the 
interpretations  at  appropriate  points.  The  developer  must  show,  and  the  evaluation 
shall  validate,  that  the  subsystem  can  be  integrated  into  a  system  to  fulfill  its 
designated  role. 

Most  all  computer  security  subsystems  will  rely  on  other  security-relevant 
functions  in  the  environment  where  they  are  implemented.  Audit  subsystems,  for 
example,  depend  on  an  identification  and  authentication  function  to  provide  the 
unique  user  identities  that  are  necessary  for  individual  accountability.  Also,  it  is 
important  to  realize  that  some  of  these  functions  may  be  dependent  on  each  other  in  a 
cyclic  fashion  (e.g.,  I&A  depends  on  DAC  and  DAC  depends  on  I&A).  In  these 
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cases,  the  cyclic  dependencies  should  be  removed  either  by  complete  integration  of 
the  functions  or  by  modularizing  the  functions  in  a  way  that  allows  linear 
dependencies.  This  latter  method  is  termed  ’’sandwiching”  and  it  requires  the  splitting 
of  one  function  and  surrounding  the  other  dependent  function  with  the  two  functions 
resulting  from  the  split.  For  example,  in  the  case  of  DAC  and  I&A  cyclic 
dependencies,  one  might  split  I&A  into  two  parts  so  that  there  is  a  system  I&A,  a 
DAC  subsystem,  and  a  DAC  module  containing  its  own  I&A  functionality. 

With  the  exception  of  object  reuse,  all  functions  implemented  by  subsystems  will 
be  dependent  on  other  functions  as  shown  in  Table  1.2.  The  functions  upon  which  any 
subsystem  is  dependent  will  be  referred  to  as  that  subsystem’s  required  supporting 
functions.  These  required  supporting  functions  must  be  present  in  the  subsystem’s 
environment  for  the  effective  integration  of  the  subsystem. 

TABLE  1.2.  Required  Supporting  Functions 


SUBSYSTEM  FUNCTION 

REQUIRED  SUPPORTING  FUNCTIONS 

Discretionary  Access  Control 

I&A 

Audit^ 

Object  Reuse 

None 

Identification  &  Authentication 

Audit^ 

DAC^ 

Audit 

I&A 

DAC^ 

Subsystems  that  are  not  self-sufficient  in  providing  required  supporting  functions 
must,  at  a  minimum,  provide  an  interface  to  their  required  supporting  functions.  The 


‘  The  audit  supporting  functions  are  required  at  D2. 

^  Audit  and/or  authentication  data  must  be  protected  through  domain  isolation  or  DAC. 
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evaluation  team  will  perform  tests  to  show  whether  the  interface  to  the  required 
supporting  functions  is  reliable  and  works  properly.  The  robustness  of  the  required 
supporting  functions  on  the  other  side  of  the  interface  will  not  be  tested,  as  the  scope 
of  the  subsystem  evaluation  is  bounded  by  the  interface. 

A  more  integrated  solution  is  for  subsystems  to  be  self-  sufficient  in  providing  all  of 
their  required  supporting  functions.  Such  subsystems  will  be  evaluated  and  assigned  a 
separate  rating  for  each  function  they  provide.  Unlike  the  previous  solution,  where 
only  an  interface  is  provided,  each  required  supporting  function  is  performed  by  the 
subsystem  and  must  be  a  part  of  the  subsystem  evaluation. 

1.4.3  WARNING 

An  overall  system  rating,  such  as  that  provided  by  the  TCSEC,  cannot  be  inferred 
from  the  application  of  one  or  more  separately-rated  subsystems.  Mechanisms, 
interfaces,  and  the  extent  of  required  supporting  functions  for  each  subsystem  may 
differ  substantially  and  may  introduce  significant  vulnerabilities  that  are  not  present  in 
systems  where  security  features  are  designed  with  full  knowledge  of  interfaces  and 
host  system  support.  Therefore,  incorporation  of  an  evaluated  subsystem  into  any 
system  environment  does  not  automatically  confer  any  rating  to  the  resulting  system. 
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2.  FEATURE  REQUIREMENTS 

2.1  DISCRETIONARY  ACCESS  CONTROL  (DAC)  SUBSYSTEMS 


2.1.1  Global  Description  of  Subsystem  F eatures 


2.1. 1.1  Purpose 

This  subsystem  provides  user-specified,  controlled  sharing  of  resources.  This 
control  is  established  from  security  policies  which  define,  given  identified  subjects  and 
objects,  the  set  of  rules  that  are  used  by  the  system  to  determine  whether  a  given 
subject  is  authorized  to  gain  access  to  a  specific  object. 

DAC  features  include  the  means  for  restricting  access  to  objects;  the  means  for 
instantiating  authorizations  for  objects;  and  the  mechanisms  for  distribution,  review, 
and  revocation  of  access  privileges,  especially  during  object  creation  and  deletion. 


2. 1.1.2  Role  Within  Complete  Security  System 

The  requirement  is  to  give  individual  users  the  ability  to  restrict  access  to  objects 
created  or  controlled  by  them.  Thus,  given  identified  subjects  and  objects,  DAC 
includes  the  set  of  rules  (group-oriented  and/or  individually-oriented)  used  by  the 
subsystem  to  ensure  that  only  specified  users  or  groups  of  users  may  obtain  access  to 
data  (e.g.,  based  on  a  need-to-  know). 

A  DAC  subsystem  controls  access  to  resources.  As  such,  it  shall  be  integrable 
with  the  operating  system  of  the  protected  system  and  shall  mediate  all  accesses  to  the 
protected  resources.  To  fully  protect  itself  and  the  resources  it  controls,  the  DAC 
subsystem  must  be  interfaced  to  the  protected  system  in  such  a  way  that  it  is 
tamperproof  and  always  invoked. 

DAC  subsystems  use  the  identifiers  of  both  subjects  and  DAC-controlled  objects 
as  a  basis  for  access  control  decisions.  Thus,  they  must  be  supplied  with  the 
identifiers  in  a  reliable  manner.  The  DAC  subsystem  may  supply  subject  identification 
for  itself  or  it  may  rely  on  an  I&A  mechanism  in  the  protected  system  or  in  another 
subsystem.  It  is  also  essential  that  DAC  subsystems  be  implemented  in  an 
environment  where  the  objects  it  protects  are  well  defined  and  uniquely  identified. 

At  the  DAC/D2  class,  the  DAC  subsystem  must  interface  with  an  auditing 
mechanism.  This  auditing  mechanism  can  be  included  within  the  DAC  subsystem,  or 
it  may  reside  elsewhere  in  the  subsystem’s  environment. 
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2.1.2  Evaluation  of  DAC  Subsystems 

Subsystems  which  are  designed  to  implement  discretionary  access  controls  to 
assist  a  host  in  controlling  the  sharing  of  a  collection  of  objects  must  comply  with  all  of 
the  TCSEC  requirements  as  outlined  below  for  features,  assurances  and 
documentation.  Compliance  with  these  requirements  will  assure  that  the  subsystem 
can  enforce  a  specifically  defined  group-oriented  and/or  individually-oriented 
discretionary  access  control  policy. 

As  a  part  of  the  evaluation,  the  subsystem  vendor  shall  set  up  the  subsystem  in  a 
typical  functional  configuration  for  security  testing.  This  will  show  that  the  subsystem 
interfaces  correctly  with  the  protected  system  to  meet  all  of  the  feature  requirements 
in  this  section  and  all  of  the  assurance  and  documentation  requirements  in  Sections  3 
and  4.  It  will  also  show  that  the  subsystem  can  be  integrated  into  a  larger  system 
environment. 

The  interpretations  for  applying  the  feature  requirements  to  DAC  subsystems  are 
explained  in  the  subsequent  interpretations  sections.  The  application  of  the 
assurances  requirements  and  documentation  requirements  is  explained  in  Sections  3 
and  4,  respectively. 

2.1.3  Feature  Requirements  For  DAC  Subsystems 


2. 1.3.1  DAC/Dl 


-  TCSEC  Quote: 

”C1:  New:  The  TCB  shall  define  and  control  access  between  named  users  and  named 
objects  (e.g.,  files  and  programs)  in  the  ADP  system.  The  enforcement  mechanism 
(e.g.,  self/group/public  controls,  access  control  lists)  shall  allow  users  to  specify  and 
control  sharing  of  those  objects  by  named  individuals  or  defined  groups  or  both.” 

-  Interpretation: 

In  the  TCSEC  quote,  ”TCB”  is  interpreted  to  mean  ”DAC  subsystem”. 


2. 1.3. 1. 1  Identified  users  and  objects 

DAC  subsystems  must  use  some  mechanism  to  determine  whether  users  are 
authorized  for  each  access  attempted.  At  DAC/Dl,  this  mechanism  must  control 
access  by  groups  of  users.  The  mechanisms  that  can  meet  this  requirement  include. 
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but  are  not  limited  to:  access  control  lists,  capabilities,  descriptors,  user  profiles,  and 
protection  bits.  The  DAC  mechanism  uses  the  identification  of  subjects  and  objects 
to  perform  access  control  decisions.  This  implies  that  the  DAC  subsystem  must 
interface  with  or  provide  some  I&A  mechanism.  The  evaluation  shall  show  that  user 
identities  are  available  to  DAC. 

2.1.3.1.2  User-specified  object  sharing 

The  DAC  subsystem  must  provide  the  capability  for  users  to  specify  how  other 
users  or  groups  may  access  the  objects  they  control.  This  requires  that  the  user  have  a 
means  to  specify  the  set  of  authorizations  (e.g.,  access  control  list)  of  all  users  or 
groups  permitted  to  access  an  object  and/or  the  set  of  all  objects  accessible  to  a  user 
or  group  (e.g.,  capabilities). 

2.1.3.1.3  Mediation 

The  checking  of  the  specified  authorizations  of  a  user  prior  to  granting  access  to  an 
object  is  the  essential  function  of  DAC  which  must  be  provided.  Mediation  either 
allows  or  disallows  the  access. 

2. 1.3.2  DAC/D2 

-  TCSEC  Quote: 

”C2:  Change:  The  enforcement  mechanism  (e.g.  self/group/public  controls,  access 
control  lists)  shall  allow  users  to  specify  and  control  sharing  of  those  objects  by  named 
individuals,  or  defined  groups  of  individuals,  or  by  both,  and  shall  provide  controls  to 
limit  propagation  of  access  rights.” 

”C2:  Add:  The  discretionary  access  control  mechanism  shall,  either  by  explicit  user 
action  or  by  default,  provide  that  objects  are  protected  from  unauthorized  access. 
These  access  controls  shall  be  capable  of  including  or  excluding  access  to  the 
granularity  of  a  single  user.  Access  permission  to  an  object  by  users  not  already 
possessing  access  permission  shall  only  be  assigned  by  authorized  users.” 

-  Interpretation: 

The  following  interpretations,  in  addition  to  the  interpretations  for  the  DAC/Dl 
Class,  shall  be  satisfied  at  the  DAC/D2  Class. 
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2.1.3.2.1  Single-user  access  granularity 

The  DAC/D2  class  requires  individual  access  controls;  therefore,  the  granularity 
of  user  identification  must  enable  the  capability  to  discern  an  individual  user.  That  is, 
access  control  based  upon  group  identity  alone  is  insufficient.  To  comply  with  the 
requirement,  the  DAC  subsystem  must  either  provide  unique  user  identities  through 
its  own  I&A  mechanism  or  interface  with  an  I&A  mechanism  that  provides  unique 
user  identities.  The  DAC  subsystem  must  be  able  to  interface  to  an  auditing 
mechanism  that  records  data  about  access  mediation  events.  The  evaluation  shall 
show  that  audit  data  is  created  and  is  available  to  the  auditing  mechanism. 


2.1. 3.2.2  Authorized  user-specified  object  sharing 

The  ability  to  propagate  access  rights  to  objects  must  be  limited  to  authorized 
users.  This  additional  feature  is  incorporated  to  limit  access  rights  propagation.  This 
distribution  of  privileges  encompasses  granting,  reviewing,  and  revoking  of  access. 
The  ability  to  grant  the  right  to  grant  propagation  of  access  will  itself  be  limited  to 
authorized  users. 

2.1.3.2.3  Default  protection 

The  DAC  mechanism  must  deny  all  users  access  to  objects  when  no  explicit  action 
has  been  taken  by  the  authorized  user  to  allow  access. 

2. 1.3.3  DAC/D3 

-TCSEC  Quote: 

”B3:  Change:  The  enforcement  mechanism  (e.g.,  access  control  lists)  shall  allow  users 
to  specify  and  control  sharing  of  those  objects,  and  shall  provide  controls  to  limit 
propagation  of  access  rights.  These  access  controls  shall  be  capable  of  specifying,  for 
each  named  object,  a  list  of  named  individuals  and  a  list  of  groups  of  named 
individuals  with  their  respective  modes  of  access  to  that  object.” 

’’Add;  Furthermore,  for  each  such  named  object,  it  shall  be  possible  to  specify  a  list  of 
named  individuals  and  a  list  of  groups  of  named  individuals  for  which  no  access  to  the 
object  is  to  be  given.” 

-  Interpretation: 

The  following  interpretation,  in  addition  to  the  interpretations  and  requirements  for 
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the  DAC/D2  class,  shall  be  satisfied  for  the  DAC/D3  class. 

2.1. 3.3.1  Access  control  lists  for  each  object 

The  DAC  subsystem  shall  allow  users  to  specify  the  list  of  individuals  or  groups  of 
individuals  who  can  access  each  object.  The  list  shall  additionally  specify  the  mode(s) 
of  access  that  is  allowed  each  user  or  group.  This  implies  that  access  control  lists 
associated  with  each  object  is  the  only  acceptable  mechanism  to  satisfy  the  DAC/D3 
requirement. 

2.1.4  Assurance  Requirements  for  DAC  Subsystems 

DAC  subsystems  must  comply  with  all  of  the  assurance  requirements  for  their 
given  class  as  indicated  below.  The  interpretations  for  these  assurance  requirements 
are  contained  in  Section  3. 

Subsystems  at  the  DAC/Dl  class  must  comply  with: 

-  System  Architecture  (Dl) 

-  System  Integrity  (Dl) 

-  Security  Testing  (Dl) 

Subsystems  at  the  DAC/D2  and  DAC/D3  classes  must  comply  with: 

-  System  Architecture  (D2) 

-  System  Integrity  (D2) 

"  Security  Testing  (D2) 

2.1.5  Documentation  Requirements  for  DAC  Subsystems 

DAC  subsystems  must  meet  the  documentation  requirements  listed  below  for  their 
target  rating  class.  The  interpretations  for  these  documentation  requirements  are 
contained  in  Section  4. 

Subsystems  at  the  DAC/Dl  class  must  comply  with: 

-  Security  Features  User’s  Guide  (Dl) 

-  Trusted  Facility  Manual  (Dl) 

-  Test  Documentation  (Dl) 

-  Design  Documentation  (Dl) 
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Subsystems  at  the  DAC/D2  and  DAC/D3  classes  must  comply  with: 

-  Security  Features  User’s  Guide  (D2) 

-  Trusted  Facility  Manual  (D2) 

-  Test  Documentation  (D2) 

-  Design  Documentation  (D2) 
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2.2  OBJECT  REUSE  SUBSYSTEMS 


2.2.1  Global  Description  of  Subsystem  Features 


2.2.1. 1  Purpose 

Object  reuse  subsystems  clear  storage  objects  to  prevent  subjects  from  scavenging 
data  from  storage  objects  which  have  been  previously  used. 

2.2. 1.2  Role  Within  the  Complete  Security  System 

Object  reuse  can  be  used  to  prevent  information  scavenging  by  erasing  information 
residue  contained  in  previously  used  storage  objects  that  have  been  released  by  the 
storage  management  system.  Object  reuse  subsystems  are  most  effective  in 
environments  where  some  security  policy  is  implemented  on  the  system. 

To  prevent  scavenging  of  information  from  previously  used  storage  objects,  object 
reuse  subsystems  must  be  fully  integrable  with  the  operating  system  of  the  protected 
system.  The  object  reuse  subsystem  must  perform  its  function  for  all  reusable  storage 
objects  on  the  protected  system  (i.e.,  main  memory,  disk  storage,  tape  storage,  I/O 
buffers,  etc.). 

Object  reuse  subsystems  must  be  interfaced  with  the  protected  system  in  such  a 
way  that  they  are  tamperproof  and  always  invoked. 

2.2.2  Evaluation  of  Object  Reuse  Subsystems 

Subsystems  which  implement  object  reuse  must  comply  with  all  of  the  TCSEC 
requirements  as  outlined  below  for  features,  assurances,  and  documentation. 
Compliance  with  these  requirements  will  show  that  the  subsystem  can  enforce  object 
reuse  adequately  to  receive  an  OR/D2  rating  for  object  reuse. 

As  a  part  of  the  evaluation,  the  subsystem  vendor  shall  set  up  the  subsystem  in  a 
typical  functional  configuration  for  security  testing.  This  will  show  that  the  subsystem 
interfaces  correctly  with  the  protected  system  to  meet  all  of  the  feature  requirements 
in  this  section  and  all  of  the  assurance  and  documentation  requirements  in  Sections  3 
and  4.  It  will  also  show  that  the  subsystem  can  be  integrated  into  a  larger  system 
environment. 

The  interpretations  for  applying  the  feature  requirements  of  object  reuse 
subsystems  are  explained  in  the  subsequent  interpretations  section.  The  application 
of  the  assurance  requirements  listed  below  is  explained  in  Sections  3  and  4, 
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respectively. 


2.2.3  Feature  Requirements  for  Object  Reuse  Subsystems 


2.2.3. 1  OR/D2 


-TCSEC  Quote: 

”C2:  New:  All  authorizations  to  the  information  contained  within  a  storage  object 
shall  be  revoked  prior  to  initial  assignment,  allocation  or  reallocation  to  a  subject 
from  the  TCB’s  pool  of  unused  storage  objects.  No  information,  including  encrypted 
representations  of  information,  produced  by  a  prior  subject’s  actions  is  to  be 
available  to  any  subject  that  obtains  access  to  an  object  that  has  been  released  back  to 
the  system.” 

-  Interpretation: 

In  the  TCSEC  quote,  ”TCB”  is  interpreted  to  mean  ’’protected  system”. 
Otherwise,  this  requirement  applies  as  stated.  The  object  reuse  subsystem  shall 
perform  its  function  for  all  storage  objects  on  the  protected  system  that  are  accessible 
to  users. 

-  Rationale/Discussion: 

Object  reuse  subsystems  must  assure  that  no  previously  used  storage  objects  (e.g., 
message  buffers,  page  frames,  disk  sectors,  magnetic  tape,  memory  registers,  etc.) 
can  be  used  to  scavenge  residual  information.  Information  remaining  in  previously 
used  storage  objects  can  be  destroyed  by  overwriting  it  with  meaningless  or 
unintelligible  bit  patterns.  An  alternative  way  of  approaching  the  problem  is  to  deny 
read  access  to  previously  used  storage  objects  until  the  user  who  has  just  acquired 
them  has  overwritten  them  with  his  own  data. 

Object  reuse  subsystems  do  not  equate  to  systems  used  to  eliminate  magnetic 
renmance. 


> 
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2.2.4  Assurance  Requirements  for  Object  Reuse  Subsystems 

Object  reuse  subsystems  must  comply  with  all  of  the  assurance  requirements 
shown  below  for  the  D2  class.  The  interpretations  for  these  assurance  requirements 
for  Object  Reuse  subsystems  are  contained  in  Section  3. 

-  System  Architecture  (D2) 

-  System  Integrity  (D2) 

-  Security  Testing  (D2) 

2.2.5  Documentation  Requirements  for  Object  Reuse  Subsystems 

Object  reuse  subsystems  must  meet  the  documentation  requirements  shown  below 
for  the  D2  class.  The  interpretations  for  these  documentation  requirements  are 
contained  in  Section  4. 

-  Security  Features  User’s  Guide  (D2) 

-Trusted  Facility  Manual  (D2) 

-  Test  Documentation  (D2) 

-  Design  Documentation  (D2) 


16 


Computer  Security  Subsystems 


FEATURE  REQUIREMENTS 


2.3  IDENTIFICATION  &  AUTHENTICATION  H&A)  SUBSYSTEMS 

2.3.1  Global  Description  of  Subsystem  Features 


2.3.1. 1  Purpose 

This  subsystem  provides  the  authenticated  identification  of  a  user  seeking  to  gain 
access  to  any  resources  under  the  control  of  the  protected  system. 

2.3. 1.2  Role  Within  Complete  Security  System 

The  I&A  subsystem  provides  an  authenticated  user  identification  needed  to 
provide  accountability  for  and  control  access  to  the  protected  system.  The  granularity 
of  user  identification  is  determined  by  the  requirements  in  this  interpretation.  The 
granularity  increases  from  group  identification  at  I&A/Dl  to  individual  identification 
at  I&A/D2. 

The  requirement  is  to  be  able  to  accurately  authenticate  the  claimed  identity  of  a 
user.  The  I&A  subsystem  must  determine  whether  a  user  is  authorized  to  use  the 
protected  system.  For  all  authorized  users,  the  I&A  subsystem  communicates  the 
identity  of  the  user  to  the  protected  system.  This  identity  can  then  be  used  by  the 
protected  system  or  other  subsystems  to  provide  accountability  for  use  of  the  system 
and  access  controls  to  protected  objects  on  the  system.  To  be  effective  and  to  protect 
the  authentication  data  it  uses,  the  I&A  subsystem  must  be  tamperproof  and  always 
invoked. 

At  I&A/D2,  it  is  important  that  all  uses  of  the  I&A  subsystem  be  recorded  in  an 
audit  trail.  The  auditing  of  these  actions  may  be  performed  entirely  by  the  auditing 
mechanism  on  the  I&A  subsystem,  or  tluough  an  interface  with  an  auditing 
mechanism  in  the  protected  system  or  another  subsystem. 

2.3.2  Evaluation  of  I&A  Subsystems 

Subsystems  which  are  designed  to  implement  I&A  must  comply  with  all  of  the 
TCSEC  requirements  outlined  below  for  features,  assurances,  and  documentation. 
Compliance  with  these  requirements  will  assure  that  the  subsystem  can  enforce,  either 
wholly  or  in  part,  a  specific  I&A  policy. 

As  a  part  of  the  evaluation,  the  subsystem  vendor  shall  set  up  the  subsystem  in  a 
typical  functional  configuration  for  security  testing.  This  will  show  that  the  subsystem 
interfaces  correctly  with  the  protected  system  to  meet  all  of  the  feature  requirements 
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in  this  section  and  all  of  the  assurance  and  documentation  requirements  in  Sections  3 
and  4.  It  will  also  show  that  the  subsystem  can  be  integrated  into  a  larger  system 
environment. 

The  interpretations  for  applying  the  feature  requirements  to  I&A  subsystems  are 
explained  in  the  subsequent  interpretations  sections.  The  application  of  the  assurance 
requirements  and  documentation  requirements  listed  in  the  next  section  is  explained 
in  Sections  3  and  4,  respectively. 


2.3.3  Feature  Requirements  for  I&A  Subsystems 


2.3.3. 1  I&A/Dl 

-TCSEC  Quote: 

”C1:  New:  The  TCB  shall  require  users  to  identify  themselves  to  it  before  beginning  to 
perform  any  other  actions  that  the  TCB  is  expected  to  mediate.  Furthermore,  the 
TCB  shall  use  a  protected  mechanism  (e.g.,  passwords)  to  authenticate  the  user’s 
identity.  The  TCB  shall  protect  authentication  data  so  that  it  cannot  be  accessed  by 
any  unauthorized  user.” 

-  Interpretation: 

The  I&A  subsystem  shall  require  users  to  identify  themselves  to  it  before 
beginning  to  perform  any  other  actions  that  the  system  is  expected  to  mediate. 
Furthermore,  the  I&A  subsystem  shall  use  a  protected  mechanism  (e.g.,  passwords) 
to  authenticate  the  user’s  identity.  The  I&A  subsystem  shall  protect  authentication 
data  so  that  it  cannot  be  accessed  by  any  unauthorized  user. 

The  I&A  subsystem  shall,  at  a  minimum,  identify  and  authenticate  system  users. 
At  I&A/Dl,  users  need  not  be  individually  identified. 

-  Rationale/Discussion: 

Identification  and  Authentication  must  be  based  on  at  least  a  two-step  process, 
which  is  derived  from  a  combination  of  something  the  user  possesses  (e.g.,  smart 
card,  magnetic  stripe  card),  some  physical  attribute  about  the  user  (e.g.,  fingerprint, 
voiceprint),  something  the  user  knows  (e.g.,  password,  passphrase).  The  claimed 
identification  of  a  user  must  be  authenticated  by  an  explicit  action  of  the  user.  It  is  not 
acceptable  for  one  step  to  be  used  as  both  identification  and  authentication.  The 
claimed  identity  can  be  public.  The  measure  used  for  authentication  must  be  resistant 
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to  forging,  guessing,  and  fabricating. 

The  I&A  subsystem  must  interface  to  the  protected  system  in  such  a  way  that  it 
can  reliably  pass  authenticated  user  identities  to  the  protected  system.  The  evaluation 
shall  show  that  authenticated  user  identities  can  be  passed  to  the  protected  system. 

2.3.3.2  I&A/D2 


-TCSEC  Quote: 

”C2:  Add:  The  TCB  shaU  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  ADP  system  user.  The  TCB  shall  also 
provide  the  capability  of  associating  this  identity  with  all  auditable  actions  taken  by 
that  individual.” 

-  Interpretation: 

The  following  interpretations,  in  addition  to  those  interpretations  for  I&A/Dl, 
shall  be  satisfied  at  the  I&A/D2  Class. 

In  the  TCSEC  quote,  ”TCB”  is  interpreted  to  mean  ’T&A  subsystem.”  The  I&A 
subsystem  shall  pass  to  the  protected  system  a  unique  identifier  for  each  individual. 

The  I&A  subsystem  shall  be  able  to  uniquely  identify  each  individual  user.  This 
includes  the  ability  to  identify  individual  members  within  an  authorized  user  group  .•’ud 
the  ability  to  identify  specific  system  users  such  as  operators,  system  administrators, 
ete. 

The  I&A  subsystem  shall  provide  for  the  audit  logging  of  security-relevant  I&A 
events.  For  I&A,  the  origin  of  the  request  (e.g.,  terminal  ID,  etc.),  the  date  and  time 
of  the  event,  user  ID  (to  the  extent  recorded),  type  of  event,  and  the  success  or 
failure  of  the  event  shall  be  recorded.  The  I&A  subsystem  may  meet  this  requirement 
either  through  its  own  auditing  mechanism  or  by  providing  an  interface  for  passing  the 
necessary  data  to  another  auditing  mechanism. 

-  Rationale/Discussion: 

The  intent  of  this  requirement  is  for  the  I&A  subsystem  to  supply  a  unique  identity 
for  each  user  to  the  protected  system.  The  subsystem  supplies  a  unique  user  identity 
which  may  or  may  not  be  used  by  an  auditing  mechanism.  This  auditing  support  is 
required  to  maintain  consistency  with  the  C2  level  of  trust  as  defined  by  the  TCSEC. 
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2.3.4  Assurance  Requirements  for  I&A  Subsystems 

I&A  subsystems  must  comply  with  all  of  the  assurance  requirements  listed  below 
for  their  given  class.  The  interpretations  for  these  assurance  requirements  to  I&A 
subsystems  are  contained  in  Section  3. 

Subsystems  at  the  I&A/Dl  class  shall  comply  with: 

-  System  Architecture  (Dl) 

-  System  Integrity  (Dl) 

-  Security  Testing  (Dl) 

Subsystems  at  the  I&A/D2  class  shall  comply  with: 

-  System  Architecture  (D2) 

-  System  Integrity  (D2) 

-  Security  Testing  (D2) 


2.3.5  Documentation  Requirements  for  I&A  Subsystems 

I&A  subsystems  must  meet  the  documentation  requirements  listed  below  for  their 
target  rating  class.  The  interpretations  for  these  documentation  requirements  are 
contained  in  Section  4. 

Subsystems  at  the  I&A/Dl  class  shall  comply  with: 

-  Security  Features  User’s  Guide  (Dl) 

-  Trusted  Facility  Manual  (Dl) 

-  Test  Documentation  (Dl) 

-  Design  Documentation  (Dl) 

Subsystems  at  the  I&A/D2  class  shall  comply  with: 

-  Security  Features  User’s  Guide  (D2) 

-  Trusted  Facility  Manual  (D2) 

-  Test  Documentation  (D2) 

-  Design  Documentation  (D2) 
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2.4  AUDIT  SUBSYSTEMS 


2.4.1  Global  Description  of  Subsystem  Features 


2.4.1. 1  Purpose 

Accountability  is  partly  achieved  through  auditing.  That  is,  data  from  security¬ 
relevant  events  is  captured  and  passed  to  the  audit  mechanism  to  be  recorded  for  use 
in  detecting  possible  security  breaches  and  providing  a  trace  to  the  party  responsible. 

2.4. 1.2  Role  Within  Complete  Security  System 

The  requirement  is  to  be  able  to  record  security-relevant  events  in  a  manner  that 
will  allow  detection  and/or  after-the-fact  investigations  to  trace  security  violations  to 
the  responsible  party. 

An  auditing  subsystem  must  be  capable  of  recording  all  security-relevant  actions 
that  take  place  throughout  the  computer  system.  To  accomplish  this  goal,  it  must 
integrate  itself  into  the  mechanisms  that  mediate  access  and  perform  user 
identification  and  authentication,  and  capture  data  about  the  events  they  control. 
Additionally,  an  audit  subsystem  must  be  interfaced  with  the  protected  system  in  such 
a  way  that  it  is  tamperproof  and  always  invoked. 

The  auditing  subsystem  must  be  provided  all  of  the  necessary  data  associated  with 
actions  as  specified  in  Section  2.4.3.  The  necessary  data  includes  the  unique  identity 
of  the  user  that  is  responsible  for  each  action.  This  implies  that  an  auditing  subsystem 
must  be  augmented  by  an  identification  and  authentication  mechanism  either  within 
the  subsystem  itself  or  elsewhere  on  the  system. 

2.4.2  Evaluation  of  Auditing  Subsystems 

Subsystems  which  are  designed  to  implement  audit  data  collection  and  control 
functions  for  a  host  must  comply  with  all  of  the  TCSEC  requirements  as  outlined 
below  for  features,  assurances  and  documentation.  Compliance  with  these  features 
will  assure  that  the  subsystem,  through  its  integration,  can  detect  or  generate  the 
relevant  audit  data  or  can  record  all  relevant  audit  data  passed  to  it  by  the  host  or 
other  subsystems. 

As  a  part  of  the  evaluation,  the  subsystem  vendor  shall  set  up  the  subsystem  in  a 
typical  functional  configuration  for  security  testing.  This  will  show  that  the  subsystem 
interfaces  correctly  with  the  protected  system  to  meet  all  of  the  feature  requirements 
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in  this  section  and  all  of  the  assurance  and  documentation  requirements  in  Sections  3 
and  4.  It  will  also  show  that  the  subsystem  can  be  integrated  into  a  larger  system 
environment. 

The  interpretations  for  applying  the  feature  requirements  to  auditing  subsystems 
are  explained  in  the  subsequent  interpretations  sections.  The  application  of  the 
assurance  requirements  and  documentation  requirements  is  explained  in  Sections  3 
and  4,  respectively. 

2.4.3  Feature  Requirements  For  Auditing  Subsystems 


2.4.3. 1  AUD/D2 


-TCSEC  Quote: 

”C2:  New:  The  TCB  shall  be  able  to  create,  maintain,  and  protect  from  modification 
or  unauthorized  access  or  destruction  an  audit  trail  of  accesses  to  the  objects  it 
protects.  The  audit  data  shall  be  protected  by  the  TCB  so  that  read  access  to  it  is 
limited  to  those  who  are  authorized  for  audit  data.  The  TCB  shall  be  able  to  record 
the  following  types  of  events:  use  of  identification  and  authentication  mechanisms, 
introduction  of  objects  into  a  user’s  address  space  (e.g.,  file  open,  program 
initiation),  deletion  of  objects,  actions  taken  by  computer  operators  and  system 
administrators  and/or  system  security  officers,  and  other  security  relevant  events. 
For  each  recorded  event,  the  audit  record  shall  identify:  date  and  time  of  the  event, 
user,  type  of  event,  and  success  or  failure  of  the  event.  For 
identification/authentication  events  the  origin  of  request  (e.g.,  terminal  ID)  shall  be 
included  in  the  audit  record.  For  events  that  introduce  an  object  into  a  user’s  address 
space  and  for  object  deletion  events  the  audit  record  shall  include  the  name  of  the 
object.  The  ADP  system  administrator  shall  be  able  to  selectively  audit  the  actions  of 
any  one  or  more  users  based  on  individual  identity.” 

-  Interpretations: 

The  following  subsections  provide  interpretations  of  the  TCSEC  requirements 
which  shall  be  satisfied  by  auditing  subsystems  at  AUD/D2. 


2.4.3.1.1  Creation  and  management  of  audit  trail 

The  auditing  subsystem  shall  create  and  manage  the  audit  trail  of  security-relevant 
events  in  the  system.  If  the  other  portions  of  the  system  are  unable  to  capture  data 
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about  such  events,  the  auditing  subsystem  shall  contain  the  necessary  interfaces  into 
the  system  to  perform  this  function.  Alternatively,  the  auditing  subsystem  might 
simply  accept  and  store  data  about  events  if  the  other  portions  of  the  system  are 
capable  of  creating  such  data  and  passing  them  on. 

-  Rationale/Discussion: 

To  meet  this  requirement,  it  is  sufficient  that  the  audit  subsystem  provides  a  set  of 
calls  which  permit  the  system  to  supply  the  needed  data  as  parameters  that  the  audit 
subsystem  puts  into  a  data  structure  and  routes  to  audit  storage  (or  transmits  securely 
to  an  audit  logger). 

2.4.3. 1.2  Protection  of  audit  data 

It  shall  be  demonstrated  that  the  audit  data  is  protected  from  unauthorized 
modification.  This  protection  will  be  provided  either  by  the  subsystem  itself  or  by  its 
integration  with  the  protected  system. 

-  Rationale/Discussion: 

The  auditing  subsystem  might  store  the  audit  data  in  a  dedicated  data  storage  area 
that  cannot  be  accessed  by  any  subject  on  the  system  except  the  auditing  subsystem 
itself  and  the  system  security  officer  (or  system  administrator)  through  the  auditing 
subsystem.  Or,  if  the  protected  system  has  adequate  access  control  facilities,  the  audit 
data  might  be  stored  on  the  protected  system,  using  its  access  control  mechanisms  for 
protection. 

2.4.3. 1.3  Access  control  to  audit 

The  audit  mechanism,  auditing  parameters,  and  the  audit  data  storage  media  shall 
be  protected  to  ensure  access  is  allowed  only  to  authorized  individuals.  Individuals 
who  are  authorized  to  access  the  audit  data  shall  be  able  to  gain  access  only  through 
the  auditing  subsystem. 

-  Rationale/Discussion: 

This  interpretation  assumes  that  discretionary  access  controls  or  physical  controls 
will  be  in  place  to  keep  unauthorized  individuals  from  gaining  access  to  the  audit  data. 


2.4.3.1.4  Specific  types  of  events 

Data  about  all  security  relevant  events  must  be  recorded.  The  other  portions  of 
the  system  shall  be  able  to  pass  data  concerning  these  events  to  the  auditing 
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subsystem,  or  the  auditing  subsystem  shall  have  the  necessary  code  integrated  into  the 
other  portions  of  the  system  to  pass  the  data  to  the  collection  point. 

2.4.3. 1.5  Specific  information  per  event 

All  of  the  specific  information  enumerated  in  the  TCSEC  quote  shall  be  captured 
for  each  recorded  event.  Of  particular  concern,  is  the  recording  of  the  user  identity 
with  each  recorded  event. 

-  Rationale/Discussion: 

This  implies  that  the  audit  subsystem  must  be  able  to  acquire  user  identities  from 
an  I&A  mechanism,  which  may  be  provided  on  the  audit  subsystem  itself,  on  the 
protected  system,  or  in  a  separate  I&A  subsystem.  Whichever  is  the  case,  the 
evaluation  shall  show  that  the  audit  subsystem  has  a  working  interface  to  an  I&A 
mechanism. 


2.4.3. 1.6  Ability  to  selectively  audit  individuals 

The  auditing  subsystem  shall  have  the  ability  to  perform  selection  of  audit  data 
based  on  individual  users. 

-  Rationale/Discussion: 

This  requirement  can  be  satisfied  by  pre-selection  of  the  information  to  be 
recorded  in  the  audit  log  (selective  logging)  and/or  by  post-selection  of  information  to 
be  extracted  from  the  audit  log  (selective  reduction).  The  reduction  of  the  audit  log 
must  be  able  to  show  all  of  the  security-relevant  actions  performed  by  any  specified 
individual.  The  intent  of  selective  logging  is  to  reduce  the  volume  of  audit  data  to  be 
recorded  by  only  recording  audit  data  for  those  specific  individuals  that  the  system 
security  officer  (or  system  administrator)  specifies.  The  intent  of  selective  reduction 
is  to  reduce  the  large  volume  of  audit  data  into  a  collection  of  intelligible  information 
which  can  be  more  efficiently  used  by  the  system  administrator. 

2.4.3.2  AUD/D3 

-TCSEC  Quote: 

”B3:  Add:  The  TCB  shall  contain  a  mechanism  that  is  able  to  monitor  the  occurrence 
or  accumulation  of  security  auditable  events  that  may  indicate  an  imminent  violation 
of  security  policy.  This  mechanism  shall  be  able  to  immediately  notify  the  security 
administrator  when  thresholds  are  exceeded  and,  if  the  occurrence  or  accumulation 
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of  these  security  relevant  events  continues,  the  system  shall  take  the  least  disruptive 
action  to  terminate  the  event.” 

-  Interpretation:  The  following  interpretation,  in  addition  to  the  interpretation  and 
requirement  for  AUD/D2,  shall  be  satisfied  for  the  AUD/D3  class. 

2.4.3.2.1  Real-time  alarms 

The  auditing  subsystem  shall  provide  the  capability  for  the  security  administrator 
to  set  thresholds  for  certain  auditable  events.  Furthermore,  when  the  thresholds  are 
exceeded,  the  audit  subsystem  shall  immediately  notify  the  security  administrator  of 
an  imminent  security  violation. 


2.4.4  Assurance  Requirements  for  Auditing  Subsystems 

Audit  subsystems,  whether  being  evaluated  at  AUD/D2  or  AUD/D3,  must 
comply  with  the  assurance  requirements  listed  below  for  the  D2  class.  The 
interpretations  for  these  assurance  requirements  are  contained  in  Section  3. 

-  System  Architecture  (D2) 

-  System  Integrity  (D2) 

-  Security  Testing  (D2) 


2.4.5  Documentation  Requirements  for  Auditing  Subsystems 

Audit  subsystems,  whether  being  evaluated  at  AUD/D2  or  AUD/D3,  must  meet 
the  documentation  requirements  listed  below  for  the  D2  class.  The  interpretations  for 
these  documentation  requirements  are  contained  in  Section  4. 

-  Security  Features  User’s  Guide  (D2) 

-  Trusted  Facility  Manual  (D2) 

-  Test  Documentation  (D2) 

-  Design  Documentation  (D2) 
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3.  ASSURANCE  REQUIREMENTS 

Rated  subsystems  must  provide  correct  and  accurate  operations.  Assurance  must 
be  provided  that  correct  implementation  and  operation  of  the  subsystem’s  function 
exist  throughout  the  subsystem’s  life  cycle.  The  objective  in  applying  these  assurance 
requirements  is  to  develop  confidence  that  the  subsystem  has  been  implemented 
correctly  and  that  it  is  protected  from  tampering  and  circumvention. 

The  requirement  is  that  the  subsystem  must  contain  hardware/software 
mechanisms  that  can  be  independently  evaluated  through  a  combination  of  inspection 
and  testing  to  provide  sufficient  assurance  that  the  subsystem  features  enforce  or 
support  the  functions  for  which  the  subsystem  is  intended.  To  receive  a  rating,  a 
subsystem  must  meet  the  assurance  requirements  at  the  same  level  of  trust  as  it  has 
met  the  requirements  for  functionality.  The  assurances  must  be  applied  to  the 
different  types  of  subsystems  as  described  in  the  previous  sections. 

3.1  SUBSYSTEM  ARCHITECTURE 

Subsystem  architecture  evaluation  is  designed  to  provide  operational  assurances 
with  regard  to  the  design  and  implementation  of  the  protection  mechanisms  of  the 
subsystem  and  its  interfaces  to  the  host/host  TCB. 

3.1.1  ArchrDI 


-  TCSEC  Quote: 

”C1:  New:  The  TCB  shall  maintain  a  domain  for  its  own  execution  that  protects  it 
from  external  interference  or  tampering  (e.g.,  by  modification  of  its  code  or  data 
structures).  Resources  controlled  by  the  TCB  may  be  a  defined  subset  of  the  subjects 
and  objects  in  the  ADP  system.” 

-  Interpretation: 

This  requirement  applies  to  all  subsystems  evaluated  at  all  classes,  regardless  of 
the  function(s)  they  perform.  There  are  two  specific  elements  of  this  requirement: 
Execution  Domain  Protection  and  Defined  Subsets. 


3 . 1 . 1 . 1  Execution  Domain  Protection 

Protection  of  the  subsystem’s  mechanism  and  data  from  external  interference  or 
tampering  must  be  provided.  The  code  and  data  of  the  subsystem  may  be  protected 
through  physical  protection  (e.g.,  by  the  subsystem’s  dedicated  hardware  base)  or  by 
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logical  isolation  (e.g.,  using  the  protected  system’s  domain  mechanism). 

-  Rationale  and  Discussion: 

The  subsystem  may  be  contained  entirely  on  its  own  hardware  base  which  must 
protect  the  operational  elements  of  the  mechanisms.  Alternatively,  all  or  a  portion  of 
the  subsystem  may  be  implemented  on  the  hardware  of  the  host,  in  which  case  the  host 
system’s  architecture  must  protect  this  portion  from  external  interference  or 
tampering. 

3. 1.1.2  Defined  Subsets 

I&A  subsystems,  when  used  for  the  system’s  I&A,  define  the  subset  of  subjects 
urider  the  control  of  the  system’s  TCB. 

DAC  subsystems  may  protect  a  subset  of  the  total  collection  of  objects  on  the 
protected  system. 

3.1.2  Arch:D2 

-TCSEC  Quote: 

”C2:  Add:  The  TCB  shall  isolate  the  resources  to  be  protected  so  that  they  are  subject 
to  the  access  control  and  auditing  requirements.” 

-  Interpretation: 

In  the  TCSEC  quote,  ”TCB”  is  interpreted  to  mean  ’’subsystem”. 

This  requirement  applies  to  all  subsystems  evaluated  at  the  D2  class  or  the  03 
class.  The  following  interpretations  explain  how  this  requirement  applies  to  specific 
functions  performed  by  subsystems. 

-  Interpretation  for  DAC  Subsystems: 

All  named  objects  which  are  in  the  defined  subset  of  protected  objects  shall  be 
isolated  such  that  the  DAC  subsystem  mediates  all  access  to  those  objects. 

-  Interpretation  for  Auditing  Subsystems: 

The  system’s  architecture  shall  ensure  that  the  auditing  mechanism  cannot  be 
bypassed  by  any  subjects  accessing  those  objects  under  the  system’s  control. 
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-  Interpretation  for  Object  Reuse  Subsystems 

The  notion  of  subsetting  objects  is  not  applicable  to  object  reuse  subsystems. 
Object  reuse  subsystems  shall  perform  their  function  for  all  storage  objects  on  the 
protected  system  that  are  accessible  to  users. 

-  Interpretation  for  I&A  Subsystems: 

This  requirement  applies  to  I&A  subsystems.  Authentication  data  shall  be 
protected  from  unauthorized  access.  Access  to  the  authentication  data  shall  also  be 
recorded  in  the  audit  trail. 

3.2  SUBSYSTEM  INTEGRITY 

Subsystem  integrity  evaluation  is  designed  to  provide  operational  assurances  with 
regard  to  the  correct  operation  of  the  protection  mechanisms  of  the  subsystem  and  its 
interfaces  to  the  protected  system. 

3.2.1  Integrity:Dl 

-TCSEC  Quote: 

”C1:  New:  Hardware  and/or  software  features  shall  be  provided  that  can  be  used  to 
periodically  validate  the  correct  operation  of  the  on-site  hardware  and  firmware 
elements  of  the  TCB.” 

-  Interpretation: 

In  the  TCSEC  quote,  ”TCB”  is  interpreted  to  mean  ’’subsystem”. 

This  requirement  applies  to  all  subsystems  evaluated  at  any  class,  regardless  of  the 
functions  they  perform. 

-  Rationale/Discussion: 

The  capability  must  exist  to  validate  the  correct  operation  of  all  hardware  and 
firmware  elements  of  the  system  regardless  of  whether  they  reside  within  the 
subsystem,  the  protected  system,  or  other  interfacing  subsystems.  If  the  hardware 
and/or  firmware  elements  of  the  protected  system  or  other  interfacing  subsystems  play 
an  integral  role  in  the  protection  and/or  correct  operation  of  the  subsystem,  then  they 
must  comply  with  this  requirement  as  though  they  were  part  of  the  subsystem. 
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3.2.2  Integrity:D2 

There  are  no  additional  requirements  for  System  Integrity  at  D2. 

3.3  SECURITY  TESTING 

Testing,  as  part  of  the  evaluation,  is  designed  to  provide  life  cycle  assurances  with 
regard  to  the  integrity  of  the  subsystem.  Further,  testing  provides  additional 
assurances  regarding  the  correct  operation  of  the  protection  mechanisms  of  the 
subsystem  and  the  subsystem’s  interfaces  to  the  protected  system.  These  mechanisms 
and  their  interfaces  to  the  protected  system,  are  termed  the  Subsystem’s  Security- 
Relevant  Portion  (SRP). 

3.3.1  Test:Dl 

-TCSEC  Quote: 

”C1:  New:  The  security  mechanisms  of  the  ADP  system  shall  be  tested  and  found  to 
work  as  claimed  in  the  system  documentation.  Testing  shall  be  done  to  assure  that 
there  are  no  obvious  ways  for  an  unauthorized  user  to  bypass  or  otherwise  defeat  the 
security  protection  mechanisms  of  the  TCB.  (See  the  Security  Testing  Guidelines.)” 

-  Interpretation: 

This  requirement  applies  to  all  subsystems  evaluated  at  any  class,  regardless  of  the 
function(s)  they  perform.  In  the  TCSEC  quote,  ”TCB”  is  interpreted  to  mean 
’’subsystem”. 

The  subsystem’s  SRP  shall  be  tested  and  found  to  work  as  claimed  in  the 
subsystem’s  documentation.  The  addition  of  a  subsystem  to  a  protected  system  shall 
not  cause  obvious  flaws  to  the  resulting  system. 

Test  results  shall  show  that  there  are  no  obvious  ways  for  an  unauthorized  user  to 
bypass  or  otherwise  defeat  the  subsystem’s  SRP. 

-  Rational/Discussion: 

Security  testing  is  a  very  important  part  of  subsystem  evaluations.  It  is  essential 
that  the  subsystem  be  demonstrated  to  operate  securely. 
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3.3.2  Tcst:D2 

-TCSEC  Quote: 

”C2:  Add:  Testing  shall  also  include  a  search  for  obvious  flaws  that  would  allow 
violation  of  resource  isolation,  or  that  would  permit  unauthorized  access  to  the  audit 
or  authentication  data.” 

-  Interpretation: 

This  requirement  applies  to  the  testing  of  the  SRP  of  any  subsystem  evaluated  at 
the  D2  class  or  the  D3  class. 

-  Rationale/Discussion: 

The  requirement  as  written  in  the  TCSEC  quote  is  directly  applicable.  This 
requirement  is  to  ensure  that  subsystems  at  D2  cannot  be  circumvented  or  tampered 
with. 
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4.  DOCUMENTATION  REQUIREMENTS 

Documentation  shall  produce  evidence  that  the  subsystem  can  and  does  provide 
specified  security  features.  The  evaluation  will  focus  on  the  completeness  of  this 
evidence  through  inspection  of  documentation  structure  and  content  and  through  a 
mapping  of  the  documentation  to  the  subsystem’s  implementation  and  its  operation. 

4.1  SECURITY  FEATURES  USER’S  GUIDE 


4.1.1  SFUG:D1 

-TCSEC  Quote: 

”C1:  New:  A  single  summary,  chapter,  or  manual  in  user  documentation  shall 
describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines  on  their  use,  and 
how  they  interact  with  one  another.” 

-  Interpretation: 

All  subsystems  shall  meet  this  requirement  in  that  they  shall  describe  the 
protection  mechanisms  provided  by  the  subsystem. 

-  Rationale/Discussion: 

It  is  recognized  that  some  subsystems  may  be  partially  or  completely  transparent 
to  the  general  user.  In  such  cases,  this  requirement  can  be  met  by  documenting  the 
functions  the  subsystem  performs  so  users  will  be  aware  of  what  the  subsystem  does. 
Other  subsystems  which  have  a  very  limited  user  interface  may  not  need  to  be 
accompanied  by  more  than  a  pocketsize  card  available  to  every  user.  In  short,  the 
documentation  required  to  meet  this  requirement  need  not  be  elaborate,  but  must  be 
clear  and  comprehensive. 

4.1.2  SFUG:D2 


-Interpretation: 

There  are  no  additional  requirements  at  the  D2  class. 
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4.2  TRUSTED  FACILITY  MANUAL 


4.2.1  TFM:D1 

-  TCSEC  Quote : 

”C1:  New:  A  manual  addressed  to  the  ADP  system  administrator  shall  present 
cautions  about  functions  and  privileges  that  should  be  controlled  when  running  a 
secure  facility.” 

-  Interpretation: 

This  requirement  applies  to  all  subsystems  in  that  the  manual  shall  present 
cautions  about  functions  and  privileges  provided  by  the  subsystem.  Further,  this 
manual  shall  present  specific  and  precise  direction  for  effectively  integrating  the 
subsystem  into  the  overall  system. 

4.2.2  TFM:D2 

-  TCSEC  Quote: 

”C2:  Add:  The  procedures  for  examining  and  maintaining  the  audit  files  as  well  as  the 
detailed  audit  record  structure  for  each  type  of  audit  event  shall  be  given.” 

-  Interpretation: 

This  requirement  applies  directly  to  all  auditing  subsystems  and  to  other 
subsystems  that  maintain  their  own  audit  data  concerning  events  that  happen  under 
their  control.  For  subsystems  that  create  audit  data  and  pass  it  to  an  external  auditing 
collection  and  maintenance  facility,  the  audit  record  structure  shall  be  documented; 
however,  the  procedures  for  examination  and  maintenance  of  audit  files  may  be  left  to 
the  external  auditing  facility. 
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4.3  TEST  DOCUMENTATION 


4.3.1  TD:D1 

-  TCSEC  Quote: 

”C1:  New:  The  system  developer  shall  provide  to  the  evaluators  a  document  that 
describes  the  test  plan,  test  procedures  that  show  how  the  security  mechanisms  were 
tested,  and  results  of  the  security  mechanisms’  hinctional  testing.” 

-  Interpretation: 

The  document  shall  explain  the  exact  configuration  used  for  security  testing.  All 
mechanisms  supplying  the  required  supporting  functions  shall  be  identified.  All 
interfaces  between  the  subsystem  being  tested,  the  protected  system,  and  other 
subsystems  shall  be  described. 

4.3.2  TD:D2 

-Interpretation: 

There  are  no  additional  requirements  at  the  D2  class. 

4.4  DESIGN  DOCUMENTATION 


4,4.1  DD:D1 

-TCSEC  Quote: 

”C1:  New:  Documentation  shall  be  available  that  provides  a  description  of  the 
manufacturer’s  philosophy  of  protection  and  an  explanation  of  how  this  philosophy  is 
translated  into  the  TCB.  If  the  TCB  is  composed  of  distinct  modules,  the  interfaces 
between  these  modules  shall  be  described.” 

-  Interpretation: 

This  requirement  applies  directly  to  all  subsystems.  Specifically,  the  design 
documentation  shall  state  what  types  of  threats  the  subsystem  is  designed  to  protect 
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against  (e.g.,  casual  browsing,  determined  attacks,  accidents).  This  documentation 
shall  show  how  the  protection  philosophy  is  translated  into  the  subsystem’s  SRP. 
Design  documentation  shall  also  specify  how  the  subsystem  is  to  interact  with  the 
protected  system  and  other  subsystems  to  provide  a  complete  computer  security 
system.  If  the  SRP  is  modularized,  the  interfaces  between  these  modules  shall  be 
described. 

4.4.2  DD:D2 

There  are  no  additional  requirements  for  Design  Documentation  at  the  D2  class. 
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5.  GLOSSARY 


Accreditation  -  The  official  authorization  that  is  granted  to  an  ADP  system  to 
process  sensitive  information  in  its  operational  environment,  based  upon 
comprehensive  security  evaluation  of  the  system’s  hardware,  firmware,  and  software 
security  design,  configuration  and  implementation  of  the  other  system  procedural, 
administrative,  physical,  TEMPEST,  personnel,  and  communications  controls. 

Audit  -  The  procedure  of  capturing,  storing,  maintaining,  and  managing  data 
concerning  security-relevant  events  that  occur  on  a  computer  system.  The  data 
recorded  are  intended  for  use  in  detecting  security  violations  and  tracing  those 
violations  to  the  responsible  individual. 

Audit  trail  -  A  set  of  records  that  collectively  provide  documentary  evidence  of 
processing  users  to  aid  in  tracing  from  original  transactions  forward  to  related  records 
and  reports,  and/or  backwards  from  records  and  reports  to  their  component  source 
transactions. 

Authenticate  -  To  establish  the  validity  of  a  claimed  identity. 

Authorization  -  Permission  which  establishes  right  to  access  information. 

Certification  evaluation  -  The  technical  evaluation  of  a  system’s  security  features, 
made  as  part  of  and  in  support  of  the  approval/accreditation  process,  that  establishes 
the  extent  to  which  a  particular  computer  system’s  design  and  implementation  meet  a 
set  of  specified  security  requirements. 

Computer  security  subsystem  -  Hardware,  firmware  and/or  software  which  are  added 
to  a  computer  system  to  enhance  the  security  of  the  overall  system. 

Group  user  -  A  user  of  a  computer  system  whose  system  identification  is  the  name  of  a 
defined  group  of  users  on  that  system. 

Individual  user  -  A  user  of  a  computer  system  whose  system  identification  is  unique,  in 
that  no  other  user  on  that  system  has  that  same  identification. 

Named  object  -  An  object  which  is  directly  manipulable  at  the  TCB  interface.  The 
object  must  have  meaning  to  more  than  one  process. 

Product  evaluation  -  The  technical  evaluation  of  a  product’s  security  features  to 
determine  the  level  of  trust  that  can  be  placed  in  that  product  as  defined  by  the  NCSC 
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evaluation  criteria  for  that  type  of  product  (e.g.,  operating  system,  database 
management  system,  computer  network,  computer  security  subsystem).  Product 
evaluations  do  not  consider  the  appHcation  of  the  product  in  the  evaluation. 

Protected  system  -  The  system  being  protected.  In  the  context  of  computer  security 
subsystems,  a  stand-alone  computer  system  or  a  computer  network  to  which  a 
subsystem  is  attached  to  provide  some  computer  security  function. 

Security  Relevant  Portion  (SRP)  -  The  protection-critical  mechanism  of  the 
subsystem,  the  subsystem’s  interface(s)  to  the  protected  system,  and  interfaces  to  the 
mechanisms  providing  required  supporting  functions.  For  most  cases,  the  SRP 
encompasses  the  entire  subsystem. 

Subsystem  -  See  ’’computer  security  subsystem.” 

System  -  The  combination  of  the  protected  system  and  the  computer  security 
subsystem. 
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